Power aware adaptation for video streaming

ABSTRACT

Power aware adaptation for a power aware video streaming system may be based on the complexity information conveyed in different ways. A complexity level of a data stream, such as a video data stream, may be selected as a function of a remaining battery power of a wireless transmit/receive unit (WTRU) and on a state set of a plurality of state sets that may be stored and/or managed by the WTRU. These state sets may correspond to, for example, different content sources and/or different complexity estimation algorithms and may be used to select the complexity level of the data stream. The data stream may then be received at the selected complexity level. The complexity level and/or a bitrate of the data stream may be adapted to accommodate, for example, the remaining battery power and/or other circumstances. The adaptation may be customized according to the objectives of use cases.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. provisional application61/773,379, filed on Mar. 6, 2013; and the benefit of U.S. provisionalapplication 61/936,838, filed on Feb. 6, 2014; the contents of bothapplications are hereby incorporated by reference herein.

BACKGROUND

The computation capability of mobile devices has increased in terms ofCPU frequency, number of CPU cores and memory size. With the advances ofSystems on Chip (SoC) and wireless communication technologies (e.g., 4Gand WiFi), the mobile platform has a valuable role in society; thenumber of mobile users is increasing, and mobile devices have takenroles beyond making voice calls. For example, a user may use a mobiledevice to access a service at any time and at any place.

Video streaming is an often requested video service for mobile platformsoperating in a wireless network. There may be many challenges tooffering high quality video services on resource-constrained andheterogeneous mobile devices. These challenges may include varyingnetwork conditions, varying display sizes, varying processingcapabilities, and battery life.

SUMMARY

Power aware adaptation for a power aware video streaming system may bebased on complexity information, which may be conveyed in a number ofways. A complexity level of a data stream, such as a video data stream,may be selected as a function of a remaining battery power of a wirelesstransmit/receive unit (WTRU) and on a state set of a plurality of statesets that may be stored and/or managed by the WTRU. These state sets maycorrespond to, for example, different content sources and/or differentcomplexity estimation algorithms and may be used to select thecomplexity level of the data stream. The data stream may then bereceived at the selected complexity level. The complexity level and/or abitrate of the data stream may be adapted to accommodate, for example,the remaining battery power and/or other circumstances. The adaptationmay be customized according to the objectives of use cases.

To reduce the amount of memory that may be used in a tracking state set,a decoder device, such as a WTRU, may set a limit on the number of statesets it may track and may delete state sets when this limit may beexceeded. The decoder device may merge state sets that may be similar,and/or may quantize complexity levels to power dissipation rate (PDR)states.

A device for power aware streaming may be provided. The device mayinclude a processor that may perform a number of actions. A complexitylevel for a data segment may be determined. For example, the complexityfor the data segment may be received from a server or via a signal. Thedata segment may be a segment of a video stream. For example, theprocessor may determine a complexity level for a data segment that maybe used by a decoder. The PDR for the complexity level may be based on apower that may be dissipated while decoding the data segment. The PDRfor the complexity level may be determined using a first battery leveland a second battery level. A state, such as a PDR state, may becalculated using the PDR. A second PDR may be determined for thecomplexity level.

The state, such as the PDR state for the complexity level, may becalculated using a first PDR and a second PDR. For example, the PDRstate may be calculated by calculating a weighted average of the firstPDR and the second PDR. As another example, the PDR state may becalculated by calculating a first weighted PDR by applying a firstweight to the first PDR; calculating a second weighted PDR by applying asecond weight to the second PDR; and setting the PDR state to theaverage of the first weighted PDR and the second weighted PDR.

An amount of power to play a video stream may be determined. Forexample, the length or duration of the video stream may be determined.The power needed to play the video stream at a complexity level may becalculated by multiplying the length or duration of the video stream bythe PDR (e.g. the PDR state) for the complexity level.

A remaining battery capacity may be determined. The power that may beused to decode and/or play a video stream at a complexity level may bedetermined. A determination may be made as to whether the power mayexceed the remaining battery capacity. If the power may exceed theremaining battery capacity, another complexity level may be used todecode and play the video stream within the remaining battery capacity.

A device for power aware streaming may be provided. The device mayinclude a processor that may be configured to perform a number ofactions. For example, a first complexity level may be determined for adata segment. The complexity level for a data segment may be determinedby receiving the complexity level from a server or via a signal. Acomputing load for a decoder may be determined. A computing thresholdmay be determined. The computing threshold may be set by a user. It maybe determined that the computing load may be above or below thecomputing threshold. A second complexity level may be selected using thecomputing load. A bit rate may be determined for the data segment.

The Summary is provided to introduce a selection of concepts in asimplified form that are further described in the Detailed Description.This Summary is not intended to identify key or essential features ofthe claimed subject matter, nor is it intended to be used to limit thescope of the claimed subject matter. Furthermore, the claimed subjectmatter is not limited to any limitations that solve any or alldisadvantages noted in any part of this disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

A more detailed understanding may be had from the following description,given by way of example in conjunction with the accompanying drawings:

FIG. 1 depicts an example HTTP-based video streaming system.

FIG. 2 depicts an example block-based video encoder.

FIG. 3 depicts example block-based video decoder.

FIG. 4 depicts an example of power usage in an example video playbackscenario.

FIG. 5 depicts an example power aware streaming system.

FIG. 6 depicts example contents that may be generated at the server sideby considering resolution, bitrate, and complexity.

FIG. 7 depicts an example of a complexity aware media presentationdescription (MPD) file.

FIG. 8 depicts an example process that may be implemented by poweradaptation logic for a quality mode.

FIG. 9 depicts an example process that may be implemented by poweradaptation logic for a multitasking environment.

FIG. 10 depicts an example system in which a decoder device may streammedia content from multiple different content sources.

FIG. 11 depicts an example of quantizing complexity levels.

FIG. 12 depicts an example of bias in computation of power dissipationstate using a reduced state set.

FIG. 13 depicts an example of interpolation for reducing or eliminatingbias when updating power dissipation states of a reduced state set.

FIG. 14A is a system diagram of an example communications system inwhich one or more disclosed embodiments may be implemented.

FIG. 14B is a system diagram of an example wireless transmit/receiveunit (WTRU) that may be used within the communications systemillustrated in FIG. 14A.

FIG. 14C is a system diagram of an example radio access network and anexample core network that may be used within the communications systemillustrated in FIG. 14A.

FIG. 14D is a system diagram of an another example radio access networkand another example core network that may be used within thecommunications system illustrated in FIG. 14A.

FIG. 14E is a system diagram of an another example radio access networkand another example core network that may be used within thecommunications system illustrated in FIG. 14A.

DETAILED DESCRIPTION

A detailed description of illustrative examples will now be describedwith reference to the various Figures. Although this descriptionprovides a detailed example of possible implementations, it should benoted that the details are intended to be exemplary and in no way limitthe scope of the application.

Power aware adaptation for a power aware video streaming system may bebased on complexity information, which may be conveyed in a number ofways. A complexity level of a data stream, such as a video data stream,may be selected as a function of a remaining battery power of a wirelesstransmit/receive unit (WTRU) and on a state set of a plurality of statesets that may be stored and/or managed by the WTRU. These state sets maycorrespond to, for example, different content sources and/or differentcomplexity estimation algorithms and may be used to select thecomplexity level of the data stream. The data stream may then bereceived at the selected complexity level. The complexity level and/or abitrate of the data stream may be adapted to accommodate, for example,the remaining battery power and/or other circumstances. The adaptationmay be customized according to the objectives of use cases.

To reduce the amount of memory that may be used in a tracking state set,a decoder device, such as a WTRU, may set a limit on the number of statesets it may track and may delete state sets when this limit may beexceeded. The decoder device may merge state sets that may be similar,and/or may quantize complexity levels to power dissipation rate (PDR)states.

A device for power aware streaming may be provided. The device mayinclude a processor that may perform a number of actions. A complexitylevel for a data segment may be determined. For example, the complexityfor the data segment may be received from a server or via a signal. Thedata segment may be a segment of a video stream. For example, theprocessor may determine a complexity level for a data segment that maybe used by a decoder. The PDR for the complexity level may be based on apower that may be dissipated while decoding the data segment. The PDRfor the complexity level may be determined using a first battery leveland a second battery level. A state, such as a PDR state, may becalculated using the PDR. A second PDR may be determined for thecomplexity level.

The state, such as the PDR state for the complexity level, may becalculated using a first PDR and a second PDR. For example, the PDRstate may be calculated by calculating a weighted average of the firstPDR and the second PDR. As another example, the PDR state may becalculated by calculating a first weighted PDR by applying a firstweight to the first PDR; calculating a second weighted PDR by applying asecond weight to the second PDR; and setting the PDR state to theaverage of the first weighted PDR and the second weighted PDR.

An amount of power to play a video stream may be determined. Forexample, the length or duration of the video stream may be determined.The power needed to play the video stream at a complexity level may becalculated by multiplying the length or duration of the video stream bythe PDR (e.g. the PDR state) for the complexity level.

A remaining battery capacity may be determined. The power that may beused to decode and/or play a video stream at a complexity level may bedetermined. A determination may be made as to whether the power mayexceed the remaining battery capacity. If the power may exceed theremaining battery capacity, another complexity level may be used todecode and play the video stream within the remaining battery capacity.

A device for power aware streaming may be provided. The device mayinclude a processor that may be configured to perform a number ofactions. For example, a first complexity level may be determined for adata segment. The complexity level for a data segment may be determinedby receiving the complexity level from a server or via a signal. Acomputing load for a decoder may be determined. A computing thresholdmay be determined. The computing threshold may be set by a user. It maybe determined that the computing load may be above or below thecomputing threshold. A second complexity level may be selected using thecomputing load. A bit rate may be determined for the data segment.

As described herein, power adaptation may be performed at the clientside. For example, power adaptation may be applied in a power awarestreaming system. Power dissipation states may be tracked, maintained,and used by a decoder device, such as a WTRU. For example, contentproviders or content sources may use different algorithms to estimatecomplexity of content, which may be related to the power dissipationassociated with decoding the content. A decoder device may recognize andadapt to these different algorithms.

Video streaming may be a requested video service for mobile platformsthat may operate in a wireless network. There may be challenges tooffering quality video services on mobile devices that may beresource-constrained. For example, network conditions may vary, displaysizes may vary, and processing capabilities may vary, and there may be abattery life. Many service providers adopt dynamic adaptive streamingover HTTP (DASH) solutions because they may allow the service providersto reuse the existing network infrastructures, especially CDN networks,and may traverse firewalls. For example, EdgeCast and Level 3 use SmoothStreaming from Microsoft, whereas Akamai and CloudFront use Dynamic HTTPStreaming from Adobe. iOS devices may support Apple's HTTP LiveStreaming.

In DASH, media may be organized into segments that may be decodable. Thecontent may be encoded at different qualities or resolutions and may bechopped into segments. The information of those contents, such asbitrate, byte range, and URL, may be described with a XML-based manifestfile (MF) called a Media Presentation Description (MPD). The client mayaccess this content through HTTP and may select the segments that mayfulfill its bandwidth or resolution criteria according to the MPD file.

FIG. 1 depicts an example HTTP-based video streaming system, such assystem 200. Captured content may be compressed and may be chopped intosmall segments. For example, segments may be between 2 and 10 secondslong in some streaming systems. At 202, the segments may be stored inone or more HTTP streaming servers and/or distributed via contentdelivery network (CDN). At the beginning of a streaming session, theclient may request and receive a MPD file from a HTTP streaming serverat 202. The client may decide which segments to request according to itscapabilities, such as its display resolution and the availablebandwidth. The client may request the appropriate segments from a serverat 202, which may send the video segments to the client per its request.The segments transmitted via HTTP may be cached in a HTTP cache serveror servers at 204. This may allow cached segments to be reused for otherusers, and may allow the system to provide streaming service on a largescale.

In some streaming systems, to save transmission bandwidth and storage,single layer video coding may be used to compress the video content andto generate different bitstreams. FIG. 2 is a block diagram illustratingan example block-based layer video encoder 300 that may be used togenerate bitstreams for a streaming system, such as streaming system200. To achieve efficient compression, a single layer encoder mayemploy, for example, spatial prediction (which may be referred to asintra prediction) at 302 and/or temporal prediction (which may bereferred to as inter prediction and/or motion compensated prediction) at304 to predict the input video signal. The encoder may also have modedecision logics 306 that may choose a form (e.g., the most suitableform) of prediction, for example, based on certain criteria, such as acombination of rate and distortion considerations. The encoder maytransform at 308 and quantize at 310 the prediction residual (which maybe the difference signal between the input signal and the predictionsignal). The quantized residual, together with the mode information(e.g., intra or inter prediction) and prediction information (such asmotion vectors, reference picture indexes, intra prediction modes, etc.)may be further compressed at an entropy coder 312 and packed into anoutput video bitstream 314. As shown in FIG. 2, the encoder may alsogenerate the reconstructed video signal by applying inverse quantizationat 316 and inverse transform at 318 to the quantized residual to obtaina reconstructed residual, and adding it back to the prediction signal at320. The reconstructed video signal may go through a loop filter process322, for example, deblocking filter, Sample Adaptive Offsets, orAdaptive Loop Filters, and may be stored in a reference picture store324 that may be used to predict a video signal.

FIG. 3 is a block diagram of an example block-based single layer decoder400 that may receive a video bitstream produced by an encoder, such asencoder 300, and may reconstruct the video signal to be displayed. Atthe decoder 400, the bitstream may be parsed by an entropy decoder 402.The residual coefficients may be inverse quantized at 404 and inversetransformed at 406 to obtain a reconstructed residual. The coding modeand prediction information may be used to obtain the prediction signalusing spatial prediction 408 and/or temporal prediction 410. Theprediction signal and the reconstructed residual may be added togetherat 412 to get a reconstructed video. The reconstructed video may gothrough loop filtering at 414, may be stored in a reference picturestore 416, may be displayed at 418, and/or may be used to decode a videosignal. A number of video coding standards that may use a block-basedencoder, such as encoder 300, and a decoder, such as decoder 400,include MPEG-2 Video, MPEG4 Visual, H.264/AVC, and HEVC.

The power endurance of mobile devices may affect applicationperformance. Power usage for a reference mobile platform may be analyzedunder various conditions. For example, power consumption of components,e.g., processor, display, internal and external memory, and radio (e.g.,GSM/3G/4G/WiFi), may be evaluated. In different applications, powerconsumption percentages among those parts may be different. For example,video playback may be an intensive power consumption application as itmay involve both computation and memory access. Moreover, video playbackmay display the pictures with sufficient luminance levels, which mayalso consume much power. FIG. 4 depicts an example of power usage in anexample video playback scenario in which CPU, graphics, and display(backlight and LCD) parts may consume power.

Power saving approaches may adaptively switch working modes according tosystem status. For example, when the system status may be idle, thedevice processor may transition to a low power state, keeping requestedmodules working to reduce power consumption. Other power savingapproaches may switch the processor's frequency adaptively. For example,when the processor's frequency decreases, the voltage of a power supplymay also decrease to reduce power consumption. The power dissipated by achip may be formulated as:

P=CV ² f

where C is the capacitance, V is the voltage and f is the switchingfrequency. The frequency of the processor may be configured fordifferent tasks. For example, because decoding complexity may bedifferent for a picture, a processor's clock frequency may be reducedwhen decoding easier to decode pictures. An encoded picture size may beused to estimate a picture's decoding time. The processor frequency maybe decreased, for example, when the estimated picture decoding time maybe less than the picture duration. To provide full-length video playbackon mobile devices, power may be allocated among different modules, suchas the display, the decoding module, etc. For example, a client devicemay decrease the luminance of display and/or skip some frame decoding ifthe system determines that the remaining power may not be sufficient toplay the remaining video.

Improving power usage efficiency to prolong the battery endurance and toprovide full-length video playback may promote delivering a satisfactoryuser experience of video streaming applications on mobile platforms.However, some streaming systems, such as DASH, may focus on networkbandwidth variation, but may not consider power usage issues in theirdesign. Power saving methods may be client side technologies and mayprevent full-length playback even at the cost of frame dropping and/ormotion jerkiness. Power saving issues for mobile devices may beaddressed based on power aware computing. For example, the server andthe client may collaborate. For example, the server may prepare thevideo content with power consumption considerations, and the client maysubscribe to presentations with different complexities according to theavailable bandwidth, remaining battery, and remaining video playbacktime.

Clients may try to decode and playback video after they receive thevideo segments from the server. For a software decoder, decoding andplayback may occupy a portion of the processor's resources to meet timecriterion. Methods may be used to prevent the processor's resources frombecoming burdened, which may prevent the client from becoming unable toplayback video smoothly when the processor struggles to decode it inreal time. For example, methods may be used to prevent the client fromdropping frames or presenting asynchronous audio and video. As anotherexample, methods may allow an improvement of the system's response timein a multi-task oriented environment.

Power aware adaptation methods may be used by a power aware adaptationcontrol module in a power aware video streaming system. These poweraware adaptation methods may achieve power savings and/or betterprocessor load balancing. Power adaptation may be implemented at theclient side, which may be applied in power aware streaming systems.

FIG. 5 is a block diagram illustrating an example power aware streamingsystem 600. The power aware streaming system 600 may include a poweraware video encoder 602, a complexity aware MPD 800, a power awareadaptation control module 604, and/or a power sensing module 606. Thepower aware adaptation control module 604 and/or the power sensingmodule 606 may be implemented in, for example, a power aware streamingclient 608. A power aware video encoder 602 may generate variousversions of video segments with different complexity levels. FIG. 6depicts a graph comparing example contents that may be generated at theserver side by considering resolution, bitrate, and complexity. In theexample shown in FIG. 6, a number of complexity levels may be availablefor a bitrate, such as at 702, 704 and 706.

In a video streaming system using DASH technology or other similar HTTPstreaming technologies, the complexity level information may be added inan MPD file, media description file, or other types of manifest filethat may be signaled to a client. FIG. 7 illustrates an example of acomplexity aware MPD file 800. A description 802 of a representationelement may include a complexity Level attribute 804 that may indicate abitstream complexity level.

Although the MPD file or other types of manifest files may be used as anexample in this disclosure to carry the complexity information, personsskilled in the art will appreciate that other types of bitstream levelor system level signaling may be used to carry the complexityinformation. For example, the complexity information may be embedded invideo bitstreams using high level parameter sets such as Video ParameterSet (VPS), Sequence Parameter Set (SPS), and the like. Complexityinformation may be conveyed in an MPEG Media Transport (MMT). Forexample, complexity information may be coded as a property element in anMMT Asset, or it may be conveyed as an MMT message to clients. The GreenMPEG Call for Proposals (CfP) may define metadata files that may be usedto carry useful information to reduce power consumptions on the devices.Such metadata files may be used to convey the complexity information.

A power aware adaptation control at the client side may adaptivelychoose segments for a receiver according to information that may beobtained from bandwidth sensing, power sensing, and/or CPU load status.The adaptation logic may promote full-length playback using theremaining battery power on a device; achieving acceptable, e.g., theimproved video quality; satisfying the currently available bandwidth;and/or achieving CPU load balancing.

Referring again to FIG. 5, power adaptation logic 604 may be customizedbased on objectives of different applications. For example, the poweradaptation logic 604 may be used in a variety of use cases such as ifthe user configures the client to a quality mode. If the user prefersquality over power, the power adaptation logic 604 may prioritizefull-length playback with the remaining power and the best availablevideo quality. If the user configures the client to a load balance mode,e.g., in a multitasking environment, the power adaptation logic 604 mayprioritize full-length playback within the processor load budget. If theuser configures the client to a power saving mode, e.g., if the userprefers to conserve the remaining battery power, the power adaptationlogic 604 may prioritize full-length playback within the processor loadbudget and/or consuming as little power as possible.

Using a power sensing module 606 of FIG. 5, a power aware client 608 maymeasure a battery level (BL) and/or may determine battery usage. Thepower sensing module 606 may use an interface that may provide thecurrent battery level. For example, the power sensing module 606 mayperiodically use a power management interface that may be provided, forexample, by an operating system such as the Android operating system,which may indicate a remaining percentage of an entire battery capacity.The power sensing module 606 may use an interface that reports batteryusage by an application or a process. For example, the Android operatingsystem may have an interface that may provide power and processor usagestatistics for one or more applications (e.g., an application) and/orthe power usage for the display. The power sensing module 606 maydetermine power usage due to video decoding and display in a multi-taskor multi-process environment. The power aware client 608 may then applythe power adaptation logic 604 to ensure efficient power usage.Adaptation may involve updating a power dissipation rate (PDR) andadapting a complexity level (CL) to satisfy configurable objectives.

The power dissipation rate (PDR) for a complexity level may be measuredand updated periodically, for example, according to the equation:

$\begin{matrix}{{{PDR}\left( {k,t_{j}} \right)} = \left\{ \begin{matrix}{{{PDR}\left( {k,t_{i}} \right)};} & {{if}\mspace{14mu} \left( {k!={CL}_{i}} \right)} \\{{PDR}\left( {{CL}_{i},t_{i}} \right)} & {{else}\mspace{14mu} {{if}\left( {{BL}_{t_{j}}=={BL}_{t_{i}}} \right)}} \\{{\left( {{BL}_{t_{i}} - {BL}_{t_{j}}} \right)/\left( {t_{j} - t_{i}} \right)};} & {{{else}\mspace{14mu} {if}\mspace{14mu} \left( {{{PDR}\left( {{CL}_{i},t_{i}} \right)}==0} \right)};{k \in \left\lbrack {{CL}_{MIN},{CL}_{MAX}} \right\rbrack}} \\\begin{matrix}{{\left( {1 - \alpha} \right){{PDR}\left( {{CL}_{i},t_{i}} \right)}} +} \\{{{\alpha \left( {{BL}_{t_{i}} - {BL}_{t_{j}}} \right)}/\left( {t_{j} - t_{i}} \right)};}\end{matrix} & {otherwise}\end{matrix} \right.} & (1)\end{matrix}$

where k is the complexity level; t_(i) is the time of the i^(th)segment; CL_(MIN) and CL_(MAX) may be the minimum and maximum complexitylevels, respectively, in the system; CL_(i) may be the complexity levelof the i^(th) segment; PDR(CL_(i), t_(i)) may be the PDR value ofcomplexity level CL_(i) at time t_(i); BL_(i) may be the remainingbattery level at time t_(i); and α may be the factor to control theupdating speed, which may be set to, for example, 0.6, in which case aPDR value may be updated using equation (1) and may be a weightedcombination of 0.6 times a current PDR observation and 0.4 times aprevious PDR state. The value of α may satisfy 0≤α≤1. Larger values of αmay be used to give more weight to the current PDR observation and mayresult in a faster updating speed, while smaller values of α may be usedto give more weight to the past PDR history as represented by theprevious PDR state, resulting in a slower updating speed. At a minimum,a value of α=0 may be employed so that an initial PDR observation may beused ongoing without further updating. At a maximum, a value of α=1 maybe used so that the most recent PDR observation is always used, and anyolder PDR history is discarded. The PDR values of α complexity value(e.g., all complexity values) at the beginning of the video session maybe initialized to 0. The PDR value of complexity levels may be updated.If the battery level does not change, then the PDR statistics may bekept. Otherwise, the PDR statistics may be updated accordingly.

When the complexity level (CL) may be adapted to satisfy configurableobjectives, the amount of power requested to playback the remainingvideo with complexity level CL_(i), denoted as PC(CL_(i), t_(i)) may beestimated as

PC(CL_(i) ,t _(i))=PDR(CL_(i) ,t _(i))*(T−t _(i))  (2)

where PDR may be calculated with equation (1) above and T is the totalplayback time.

The client may decide whether to switch up or down or to keep thecurrent complexity level according to the customized objectives. Thepower adaptation logic 604 may try to achieve full-length video playbackbefore the battery power may be exhausted.

FIG. 8 depicts an example process that may be implemented by poweradaptation logic for a quality mode. For example, example process 900that may be implemented by the power adaptation logic 604 (show in FIG.5) for a quality mode, which may provide a video quality given theremaining battery level and the available bandwidth. At 902 and 904,respectively, the bandwidth statistics and the power statistics for acurrent complexity level (CL) may be updated. At 906, the powerconsumption (PC) may be estimated for a complexity level or complexitylevels for the remaining video playback.

At 908, it may be determined whether the power consumption for thecurrent complexity level may be less than the remaining battery life(BL_(rem)); whether the current complexity level may be less than themaximum complexity level; and whether the power consumption for the nexthigher complexity level may be less than the remaining battery life,e.g., whether it may be feasible to play the remaining video at the nexthigher complexity level given the remaining battery life. This mayprevent the client from switching up and down too frequently and maypromote smoother decoded video quality. This decision may be made basedon the PDR learned from previous statistics during playback. If theseconditions may be met, the decoder may be notified at 910 to switch to anormal decoding mode, and the complexity level may be switched upward.The segment may be downloaded at the adjusted complexity level andselected bitrate at 912.

If, at 908, it may be determined that a condition may not be true, itmay be determined at 914 whether the power consumption for the currentcomplexity level may be greater than the remaining battery life andwhether the current complexity level may be higher than a minimumcomplexity level. If so, the complexity level may be switched downwardat 916. The complexity level may be switched downward by switching to anext lower complexity level. This approach to switching down thecomplexity level may enable the complexity level to be switched downgradually to allow a smoother quality transition.

The complexity level may also be switched downward by searching for acomplexity level for which the remaining power may be enough to playbackthe remaining video. This may be done using, for example, the followingin Table 1:

TABLE 1 k = CL_(i) −1;   While (PC(k, t_(i)) > BL_(t) _(i) && k >CL_(MIN) )  k = k−1;

This approach may switch the complexity level downward more quickly tosave more power. However, if this switching method erroneously decidesto switch down too many levels, e.g., if the PDR estimation given byequation (1) may not be accurate enough, the power adaptation logic maydecide later to switch the complexity level up again. Regardless of howthe complexity level may be switched downward, the segment may then bedownloaded at the adjusted complexity level and selected bitrate at 912.

Similarly, gradual or more aggressive logics may also be applied whenthe client decides whether to switch up complexity level or not. Forexample, a more gradual switch up method may switch up by one complexitylevel at a time, as shown in FIG. 8, whereas a more aggressive switch upmethod may switch up to the next highest complexity level that may befeasible. A more aggressive method may not only cause larger videoquality changes due to more frequent switching, as in the case ofswitching the complexity level downward, but may also run a higher riskof using up the battery power before full-length playback may beachieved.

At 914, it may be determined that the power consumption for the currentcomplexity level may not be greater than the remaining battery life,e.g., there may be insufficient battery power to playback the video atthe current complexity level, or the current complexity level may not behigher than the minimum complexity level (e.g., the lowest complexitylevel available from the server is already being used). At 918 and 920it may be determined whether the power consumption for the current (e.g.minimum) complexity level may be greater than the remaining battery lifeand/or whether the bitrate (BR) may be the minimum bitrate. If thelowest bitrate may be reached and the power consumption for the current(e.g. minimum) complexity level may be greater than the remainingbattery life, e.g., there may be insufficient battery power to playbackthe video at the current (e.g. minimum) complexity level, at 922 thecurrent (e.g. minimum) complexity level may be kept, and the decoder maybe switched to a lower power decoding mode. For example, in-loopfiltering, such as deblocking and/or SAO in HEVC may be bypassed fornon-reference frames. The segment may then be downloaded at thecomplexity level and bitrate at 912.

If the power consumption for the current complexity level may be greaterthan the remaining battery life, but the minimum bitrate may not havebeen reached, at 924 the bitrate may be switched to a lower bitrate, andthe complexity level may be set to a new complexity level at the lowerbitrate, for example, a higher complexity level or the highestcomplexity level at the lower bitrate. The segment may be downloaded atthe new (e.g. higher or highest) complexity level and lower bitrate at912.

If, at 918, it may be determined that the power consumption for thecurrent complexity level may not be greater than the remaining batterylife, it may be determined at 926 whether the complexity level may bethe highest complexity level and the bitrate may be less than themaximum bitrate. If both of these conditions may be true, at 928 thebitrate may be switched to a higher bitrate, and the complexity levelmay be set to a new complexity level at the higher bitrate, for example,a lower or the minimum complexity level at the higher bitrate. If not,the current complexity level may be kept at 930.

FIG. 9 depicts an example process 1000 that may be implemented by poweradaptation logic, such as power adaptation logic 604 (shown in FIG. 5)for a multitasking environment. Some of the decisions and actionsperformed in the process 1000 may be similar to decisions and actionsthat may be performed in the process 900 and may be indicated by similarreference numerals. The process 1000 may involve a number of decisionsand actions that may not be performed in the process 900. The process1000 may involve decisions and actions that may be used by the client tobalance the system load while trying to provide full-length playback.Before checking remaining power, at 1032, the client may check if thesystem may be overloaded or not by measuring average CPU usage during ashort period. If the system may be overloaded, it may switch down thecomplexity level at 1034 until the complexity level reaches a minimumbound CL_(MIN). If the system may still be overloaded at CL_(MIN), theclient may switch to a lower bitrate representation and may set thecomplexity level to a new complexity level (e.g., a higher or thehighest complexity level) at 1036 if current bitrate may be greater thanthe lowest bitrate (BR_min). If the client reaches the lowest bitrateand the lowest complexity level, it may notify the decoder to apply alow complexity decoding mode at 1038 to reduce operations, for example,by skipping some in-loop filtering operations for non-reference frames.If the system processor may not be overloaded, then it may apply thesame power aware adaptation logic as in the process 900 to provide thefull-length playback. Though not shown in FIG. 9, when the systembecomes overloaded, the client may switch down bit rates before itswitches down complexity levels. For example, the client may switch to alower bit rate before it may reach the minimum complexity levelCL_(MIN), or the client may ignore complexity levels and only switch tolower bit rates.

In a power saving mode, the client may choose the lowest complexitylevel at the lowest bitrate to minimize the power consumption duringvideo playback. If the remaining power may not be enough for full-lengthplayback, the client may notify the decoder to apply additional powersaving decoding modes, such as those described herein.

If switching down to the available lower complexity and lower bitratecontent versions may not reduce the complexity enough additional powersaving modes may be employed within the logic of FIGS. 8 and 9. Forexample, some in-loop filtering may be skipped, processor switchingfrequency may be reduced, display power may be reduce, decoding someframes may be skipped, or the like.

Adaptation decisions may be based on factors such as the remainingbattery level, the availability of multimedia content segments atdifferent complexity levels and bitrates, and/or power dissipationstates tracked by the decoder device. For example, the decoder devicemay track power dissipation states according to equation (1). Theresulting power dissipation states PDR(k, t_(j)) may provide adevice-specific understanding of a power dissipation rate that may beexpected for a number of complexity levels k.

Power dissipation states may be tracked, maintained, and used by adecoder device, such as a WTRU. Different content providers or contentsources may use different algorithms to estimate complexity. Signaledcomplexity level values from one content source may map to differentpower dissipation rates than signaled complexity levels from a differentcontent source. A decoder device may recognize this and may adapt to theuse of different algorithms to estimate complexity.

Power dissipation data observed by a decoder device may be sparse, e.g.,there may not be much data observable at a given complexity level. Thismay be true, for example, at the beginning of a streaming session (e.g.,before the power dissipation states have been updated using enoughobserved data) and may be consistently true if the content providersignals complexity level values with fine granularity, e.g., ComplexityLevel (CL)=1, 2, 3, . . . 500.

A decoder device may have limited memory for state tracking. A decoderdevice may manage the state memory while still accurately tracking powerdissipation states.

FIG. 10 depicts an example system 1100 in which a decoder device 1102,e.g., a WTRU, may stream media content from multiple different contentsources 1104, 1106, 1108, 1110. These content sources may be differentcontent web sites, content providers, content services, etc. Forexample, a first source 1104 may be YouTube, and a second source 1106may be CNN Video. The different content sources may provide multipleversions of content at different complexity levels and/or different bitrates, as described herein. Complexity level estimates may be providedfor the available content versions. The media content from differentcontent sources may have been encoded using different encoding tools.For example, the source 1104 may provide content encoded using a firstvideo encoder, and the source 1106 may provide content encoded using asecond video encoder. The different encoding tools may be provided bydifferent encoder vendors, for example.

The complexity estimation algorithm may be standardized across contentsources. However, as disclosed herein, a decoder device may track powerdissipation states based on its own observations of battery usage whenplaying back video at the various signaled complexity levels. This mayallow the decoder to interpret the complexity levels for differentdecoding resources in light of the power dissipation performance. Thecomplexity estimation algorithm used by the content sources may not bestandardized across content sources. A content source may customize acomplexity estimation algorithm based on its own requests, and thecomplexity estimation algorithm may also be changed and improved overtime. The decoder devices may adapt to changes in the complexityestimation algorithm.

Different content sources may provide complexity level estimatesgenerated using different complexity estimation algorithms. Thecomplexity level estimates provided by one content source may not becompatible with the complexity level estimates provided by a differentcontent source. For example, a first content source may providecomplexity level estimates using integers from 1 to 10, and a secondcontent source may provide complexity level estimates using integersfrom 1 to 100. While different value ranges or complexity scales maymake for incompatibility, other algorithm differences may also renderthe complexity estimates from one content source incompatible with thecomplexity estimates from another content source. For example, onecontent source may give a particular weighting to addition operationsand a different weighting to multiplication operations when creating thecomplexity estimation value. Another content source may factor in theavailability of specialized decoding hardware to the complexityestimate. A complexity level value (e.g., “ComplexityLevel=10”) signaledby a first content source may correspond to one power dissipation rate,and the same complexity level value signaled by a second content sourcemay correspond to a different power dissipation rate, from the point ofview of a decoder device.

The decoder device 1102 may track multiple state sets that maycorrespond to different complexity estimation algorithms that may beused by different content sources. As illustrated in FIG. 10, thedecoder device 1102 may have multiple state sets 1112, and may have astate manager component 1114 that may be used to create and manage themultiple state sets 1112. A multiple state set may comprise a set ofpower dissipation states computed from observations of power dissipationwhile decoding various segments of video at different advertisedcomplexity levels. For example, a state set may have power dissipationstates PDR(k, t_(j)) as computed using equation (1). A state set may beconstructed from power dissipation data observed during a singlestreaming session, or from data observed across multiple streamingsessions. For purposes of brevity, the t_(j) may be omitted from thenotation PDR(k, t_(j)); accordingly, the notation PDR(k) may represent arecent power dissipation rate states for complexity level k.

State sets may correspond to different content sources. For example, asshown in FIG. 10, a decoder device may maintain a different state setfor a content source. Different state sets may correspond to differentcontent web sites, content providers, or content services. For example,the decoder device may distinguish content sources using a domain name(e.g. youtube.com vs. cnn.com) and may maintain a different state setfor each domain from which content may be streamed. The state set may bemaintained across multiple streaming sessions, so that compatibleobservations may be collected to the proper state set. This techniquemay resolve issues of data sparsity, and may allow the decoder device tobegin a streaming session with an already developed state model.

The decoder device 1102 may have a first streaming session in whichcontent may be streamed from YouTube. In response, the state manager1114 may create and initialize a new state set, and the state set may beprogressively updated based on observations of the power dissipationrate in light of the complexity level labels provided by YouTube for thevarious content segments. The power dissipation states may be updatedduring the first streaming session using Equation (1), for example. Thedecoder device may end the first streaming session and may engage inother streaming sessions with other content sites resulting inadditional (e.g., separate) state sets being created or updated. Thedecoder device may have a second streaming session in which content maybe streamed from YouTube. The decoder device may recognize that a stateset for YouTube may exist. For example, the decoder device may match thedomain name (youtube.com) from the new streaming session to the samedomain name associated with an existing state set. Based on thisrecognition/matching, the decoder device may utilize the existingYouTube state set for the second streaming session. For example, thedecoder device may begin the second streaming session with the developedpower dissipation states from the existing state set. The decoder devicemay use these previously stored power dissipation states to driveadaptation decisions from the beginning of the second streaming session.The decoder device may progressively update the existing state set usingpower dissipation rate observations from the second streaming session,e.g., based on equation (1).

State sets may correspond to different complexity estimation algorithms,regardless of the content source. For example, a first content sourcemay provide content encoded using a third party encoding tool, such asthe Acme Encoder v1.0, and this encoding tool may have a built-inalgorithm to estimate the complexity of the video segments it encodes. Asecond content source may provide different content encoded using thesame third party encoding tool. The first content source and the secondcontent source (e.g., two different content sources) may providecomplexity level estimates produced by the same complexity estimationalgorithm, such as the complexity estimation algorithm embedded in thethird party encoding tool. An identifier, e.g., a complexity estimationidentifier (CEID), may be provided to the decoding device together withthe complexity level estimates so that the decoding device maydistinguish different complexity estimation algorithms. The decodingdevice may create and/or maintain a different state set for eachdifferent complexity estimation algorithm it may encounter, regardlessof the content source.

The CEID may be, for example, an identification string or number thatidentifies a complexity estimation algorithm. The CEID may be assignedby a registration authority. Alternately, the CEID may be created,assigned, or randomly generated by the provider of the complexityestimation algorithm. For example, the provider may generate anidentification string, e.g., “Acme-CEID-Version-1-0-5” or a GloballyUnique Identifier (GUID) number, e.g., “138294578321” to distinguishcomplexity estimates provided by a particular version of Acme videoencoding software. Such a GUID number may be random. The provider mayprovide a different identification string or a different random numberto distinguish complexity estimates provided by a different version ofits software. The provider may make the CEID available to the contentsource that uses the encoding software so that the content source maysignal the CEID to the decoder device together with the complexity levelestimate values. This may be done in an automated way. For example, aversion of the encoder software may be aware of the CEID correspondingto the complexity level estimation algorithm embedded in the software,and the software may output the CEID along with the complexity levelestimates when encoding content. The software may be capable ofgenerating raw data for inclusion in an MPD file advertising the encodedcontent, or may be capable of generating the MPD itself. The data or theMPD produced by the software may include the CEID in addition to thecomplexity level estimates. A field (e.g.,ComplexityEstimationAlg=“Acme-CEID-Version-1-0-5”) may carry the CEIDwithin the MPD or within another suitable signaling channel.

A decoder device may recognize the same CEID when streaming content fromdifferent content sources, may recognize that the complexity levelestimate values associated with such content were produced by the samecomplexity estimation algorithm, and may utilize the same state set forcontent with the same advertised CEID.

A decoder device may recognize that some content available from acontent source may have been produced using a first complexityestimation algorithm corresponding to a first CEID, and that othercontent available from the same content source may have been producedusing a second complexity estimation algorithm corresponding to a secondCEID. The decoder device may use two different state sets to track powerdissipation rates for content corresponding to the two different CEIDs.For example, a content site may update its encoding software and/or itscomplexity estimation algorithm on a certain date, such that contentencoded before the date may be associated with one CEID, and contentencoded after the date may be associated with a different CEID. Adecoder device may recognize the two distinct CEIDs and may maintain twodifferent state sets corresponding to the two different CEIDs.

A decoder device may utilize a state set when it encounters a CEID thatit recognizes as associated with the state set. If the decoder devicedoes not have a state set corresponding to a CEID it encounters whilestreaming, then the decoder device may create a state set associatedwith the newly encountered CEID.

A decoder device, e.g., a state manager on a decoder device, may haveand/or may use management functions to reduce or limit the number ofstate sets that the decoder device tracks. For example, the managementfunctions may detect when a state set may not have been used for a timeperiod (e.g., unused for two weeks), or when a state set has been usedseldomly (e.g., used two or fewer times in a three-month period). Thismay be the case, for example, if the content source may not be a popularcontent source or if the user of the decoder device infrequently streamsfrom a particular content source. This may also be the case, forexample, if the complexity estimation algorithm corresponding to a CEIDmay be used seldomly by content sources that the decoder device may belikely to encounter. The management functions may delete a state setwhich may be unused or used seldomly, thus saving memory on the decoderdevice.

A decoder device may have a limit (e.g., an upper limit) to the numberof state sets it may track and/or to the amount of memory it may use fortracking state sets. The management functions may detect when suchlimits may be exceeded and may delete one or more state sets to bringthe number of state sets or the memory used to store state sets backunder the limit. The state sets may be deleted based on a reversepriority order; for example, the least frequently used state sets may bedeleted first.

Deletion of state sets to reduce state set memory may be performedduring a streaming session. For example, if a streaming session involvesthe creation of a state set, and creating the state set may cause thedecoder device to exceed a maximum number of state sets, a managementfunction may be called during the streaming session to delete the lowestpriority (e.g., least frequently used) pre-existing state set to makeroom for the new state set. Deletion of state sets may be performedbetween streaming sessions or during idle periods.

The decoder device may delete a state set that may have been useful fora later streaming session. The decoder device may create a state set andbegin tracking power dissipation states at the beginning of thestreaming session. While the benefits of using a pre-existing state setmay be lost in this case, the system may still function and may be ableto make adaptation decisions based on the newly created state set.

State sets may be merged opportunistically. A decoder device may detectthat two state sets may be similar so that the state sets may be merged.For example, two or more content sources may use the same complexitylevel estimation algorithm, but may not advertise CEIDs, such that thedecoder device may not be able to tell from the top level signaling thatthe complexity level estimation algorithms may be the same. The decoderdevice may compare the two state sets and may determine similarity. Ifsimilarity may be determined, the decoder device may merge the two statesets and reduce the overall number of state sets maintained by thedecoder device. Detection of similarity across state sets may be basedon a variety of factors.

State sets may be sufficiently evolved to permit evaluation orcomparison. For example, the decoder device may track the number ofpower dissipation observations used to construct a state set or thetotal playback time observed to construct the state set. The decoderdevice may apply a threshold to consider a state set mature enough forcomparison. The threshold may be global to the state set. An examplethreshold may be that a state set may be mature enough to permitcomparison when it has been updated using at least eight minutes ofvideo playback. The threshold may be applied per power dissipationstate. An example threshold may be that a state set is mature enough topermit comparison once a power dissipation state PDR(k) has been updatedbased on at least five video playback segments.

State sets may have compatible complexity level values to permitevaluation or comparison. For example, a first state set may evolve suchthat it may have states for PDR(k) with kϵ{1, 2, 3, . . . 10}. The firststate set may be compared to a second state set that may also haveevolved to have states for PDR(k) with kϵ{1, 2, 3, . . . 10}. It may bedifficult to compare the first state set with a third state set that mayhave evolved to have states for PDR(k) with kϵ{20, 25, 30, 35, 40, 45,50}. If two state sets may be produced based on a different set or adifferent range of signaled complexity level values, the underlyingcomplexity estimation algorithms may not be directly comparable.Although not shown in FIG. 7, additional signaling may be added to theMPD and/or sent via external/alternative means to indicate the fullrange of complexity level values used by the server and/or the encoder.This may allow the device to more easily detect the full range ofcomplexity level values (e.g., instead of having to make multipleobservations of the complexity levels in multiple video segments) usedby different content sources, servers, and/or encoders and to moreeasily assess the similarity of the underlying complexity estimationalgorithms used by different content sources, servers, and/or encoders.If CEID is used, the full range of complexity levels may be signaledtogether with each CEID.

State sets may be compared using a suitable comparison metric. For apair of state sets where both state sets may be sufficiently evolved forcomparison, and both state sets may have compatible complexity levelvalues, the state sets may be compared using a comparison metric. Forexample, the power dissipation states may be put in vector form and anorm of the difference between the two state vectors may be computed.The norm may be an L¹ norm or an L² norm, for example. The norm of thedifference may be compared to a threshold, and if the norm may be undera threshold, the two state sets may be considered similar enough thatthe state sets may be merged. Other comparison metrics may be used. Forexample, a decoder device may compute a difference between correspondingstates of one state set and another state set, and may compare thismetric to a threshold in order to determine whether two state sets maybe sufficiently similar to merge.

In some cases, state sets may be compared if they may be produced basedon different sets or different ranges of signaled complexity levelvalues to account for the possibility that some states of a state setmay not yet have any data observations or may have insufficient dataobservations to be considered a reliable metric for power dissipation ata signaled complexity level. For example, a state set may have maturestate values for PDR(k) with kϵ{1, 2, 3, 4, 5, 7, 8, 9, 10}, but mayhave insufficient data or no data to update the state for k=6. Despitehaving a state without data, the remaining mature states maysufficiently characterize the state set to allow comparison with otherstate sets.

In such cases, the state set may be compared to other state sets. Forexample, states that may not be mature or that may not be available ineither of the two state sets under comparison may be removed from thecomparison, and corresponding states that may be mature (e.g., that mayhave been updated using a small amount of data, such as a minimum amountof data, for example, as determined by a threshold) may be compared inorder to determine the similarity. For example, if the state for k=6 isdetermined to be not mature or not available in a first state set, thefirst state set may be compared to a second state set by removing thestate value fork k=6 from both state sets, and comparing the resultingreduced state sets using a comparison metric (e.g., the L² norm of thedifference between the reduced state set vectors). States that may notbe mature or that may not be available in a state set may beinterpolated from neighboring states that may be mature in the samestate set. For example, linear interpolation may be used to fill inmissing or immature states to allow a full comparison to another stateset to be made.

If a decoder device determines sufficient similarity between state sets(e.g., as disclosed herein), then the decoder device may merge the statesets. This may reduce the total number of state sets tracked by thedecoder device, which may save memory.

The data for a state of the two state sets to be merged may be averagedto produce a corresponding state of the merged state set. This may bedone as a simple average, or it may be done as a weighted average, e.g.,

PDR_(merged)(k)=A·PDR₁(k)+B·PDR₂(k)

The weights A and B may allow weighting based on how much data may havebeen used to construct the component state sets. For example, if 28minutes of video data may have been used to construct and update thefirst state set corresponding to PDR₁(k), and 12 minutes of data mayhave been used to construct and update the second state setcorresponding to PDR₂(k), then the weights may be computed as a fractionof the total data, e.g., A may be 28/(28+12)=0.7, and B may be12/(28+12)=0.3.

The merged state set may be associated with contexts that may have beenvalid for the component state sets that may have merged. For example, ifa first state set corresponding to YouTube may be merged with a secondstate set corresponding to CNN video, the resulting merged state set maybe associated with both YouTube and CNN video. The state sets may beassociated with contexts, for example, via domain names, content servicenames or identifiers, and/or CEIDs as disclosed herein. A merged set maycorrespond to more than two such contexts, as may be the result ofmultiple merges. When a merged state set may be created and associatedwith appropriate contexts, the component state sets that contributed tothe merge may be deleted.

The decoder device or its state manager may perform state setcomparisons and merging during a streaming session (e.g., in reaction tothe current state set in use evolving to a point where it may be matureenough for comparison, or to a point where it may be sufficientlysimilar to another existing state set to be merged). Comparisons andmerging may be done outside of an active streaming session, e.g.,periodically as a housekeeping activity or during idle periods.

Merging of state sets may reduce the overall state set memoryrequirements, and may reduce the number of distinct state sets that maybe tracked by the decoder device. By combining the data from two or moresimilar state sets, issues of data sparsity may be resolved.

PDR states may be quantized. The state tracking technique described byequation (1) may assign a state to a complexity level k that may besignaled by a content source. For example, if a content source signalscomplexity levels k with kϵ{1, 2, 3, . . . 10}, a state set may beproduced with ten corresponding values, PDR(k) with kϵ{1, 2, 3, . . .10}. If a content source may use a fine granularity of complexity levels(e.g., complexity levels k with kϵ{1, 2, 3, . . . 1000}), tracking astate for a possible complexity level may increase the memory used fortracking the state set, and may also result in a data sparsity issue.For example, the decoder device may not see enough data at a complexitylevel to reliably compute a corresponding power dissipation state.

The decoder device may quantize the complexity level space to a numberof discrete bins. A bin may correspond to a power dissipation ratestate. Data observations from multiple neighboring complexity levels maybe fed into a bin, and the storage size and tracking complexity for astate set may be reduced and/or limited.

FIG. 11 depicts an example of quantizing complexity levels. As shown inFIG. 11, complexity levels 1202 that may be signaled by a content sourcemay range from CL_(min) to CL_(max). The decoder device may divide thisrange into a number of bins, such as at 1204, 1206, 1208, 1210, and1212. While FIG. 11 illustrates an example of five bins 1204, 1206,1208, 1210, 1212, more or fewer bins may be used. For example, a largernumber of bins (e.g., ten bins or twenty, bins) may be used tocharacterize the relationship between complexity level and powerdissipation rate.

The decoder device may request and/or receive a video segment associatedwith a signaled complexity level, CL. While playing back the videosegment, the decoder device may observe the changing battery leveland/or may compute a power dissipation rate for the playback of thevideo segment. The decoder device may map the signaled complexity levelto the appropriate bin, as illustrated in FIG. 11. The decoder devicemay use the observed battery levels and/or the computed powerdissipation rate to update a power dissipation state corresponding tothe mapped bin. The update may be done according to equation (1), withthe appropriate mapping of signaled complexity level CL to mapped bin k.

A state set with a small number of states (e.g., five states as shown inFIG. 11) may be produced from a more dense set of complexity levelssignaled by a content source. A value PDR(k) from this small state setmay correspond to the power dissipation rate for the complexity level(CL) value in the center of a bin k. This may be illustrated in FIG. 11by the unfilled circles 1214, 1216, 1218, 1220, 1222 at the center of abin. The values PDR(k) may be used to predict the power dissipationrates corresponding to the bin centers. To predict power dissipationrates corresponding to other values of CL, interpolation may beemployed. For example, linear interpolation or polynomial interpolationmay be used to interpolate between neighboring values of PDR(k). Areduced state set may be used to predict power dissipation rates for anysignaled value of CL, and the reduced state model may be used to driveadaptation decisions. Although not shown in FIG. 11, non-uniformquantization of the full range of complexity level values may be used.For example, finer quantization may be applied to the complexity levelvalues in the middle (that is, the middle bins may be mapped to a smallnumber of complexity levels, for example 3 complexity level valuesinstead of 6 complexity levels as shown), and coarser quantization maybe applied to the complexity level values on the left/right sides (thatis, the left/right side bins may span a larger number of complexitylevels, for example 9 complexity level values instead of 6 complexitylevels as shown).

The alignment of complexity values relative to bin dividers mayintroduce a bias into the power dissipation rate updates when a reducedstate set model may be used. The frequency of use of complexity levelsmay introduce a bias. For example, as illustrated in FIG. 12, a signaledcomplexity level 1302 aligned near an edge 1304 of a bin 1306 may beplayed back frequently during the evolution of the reduced state set,while other signaled complexity levels 1308 within the bin 1306 may beplayed back less frequently. The data used to represent the bin 1306 maybe biased toward one side of the bin 1306, and the resulting state valuePDR(k) may not accurately represent the center of the bin 1306.

To reduce or eliminate this source of bias, the observed or computedvalues of battery level change or power dissipation may be remapped toequivalent values corresponding to the center of bin k, before usingsuch values to update the power dissipation rate state PDR(k). Forexample, the decoder device may store observations of complexity levelCL and power dissipation rate PDR_(orig)(CL) corresponding to theoriginal complexity level space. As shown in FIG. 13, the decoder devicemay use interpolation to interpolate between neighboring values 1402,1404 of ((CL, PDR_(orig)(CL)) to determine a mapped value 1406 of powerdissipation rate corresponding to the center of bin k. This mapped powerdissipation rate may be used to update PDR(k), the power dissipationrate state corresponding to bin k of the reduced state set.

While FIG. 13 illustrates the use of linear interpolation, other typesof interpolation (e.g., polynomial interpolation, etc.) may be used.Interpolation may be used to remap an original power dissipation rate toan equivalent rate at the center of the bin. For example, a decoderdevice may interpolate between a power dissipation observation and apower dissipation rate state value of α neighboring bin. In FIG. 13,this may correspond to replacing (CL₂, PDR_(orig)(CL₂)) on the rightside of the interpolation with (CL_(equiv)(k+1), PDR(k+1)), which maycorrespond to the equivalent complexity level and the power dissipationrate at the center of the next higher bin. Interpolation may be doneusing either the next higher bin (e.g., k+1) or the next lower bin(e.g., k−1), depending on whether the current complexity levelobservation CL₁ is to the left or right, respectively, of the center ofbin k. Remapping to the center of bin k may be performed without storingmultiple power dissipation rate values.

A decoder device may use approaches disclosed herein to develop multiplereduced state sets having the same number of reduced state sets N. Forexample, the decoder device may create and maintain multiple state sets(e.g., corresponding to different content sources), where a state setmay be a reduced state set comprising state values PDR(k), kϵ{1, 2, 3, .. . N}. Because state sets may be based on the same reduced set ofcomplexity levels k, the state sets may be more easily compared formerging. Pairs of state sets of the order-N reduced state sets may havecompatible complexity level values that may permit evaluation orcomparison. Comparison for potential merging may be performed for pairsof the order-N reduced state sets that may have sufficiently mature datato permit a comparison.

FIG. 14A is a diagram of an example communications system 100 in whichone or more disclosed embodiments may be implemented. The communicationssystem 100 may be a multiple access system that provides content, suchas voice, data, video, messaging, broadcast, etc., to multiple wirelessusers. The communications system 100 may enable multiple wireless usersto access such content through the sharing of system resources,including wireless bandwidth. For example, the communications systems100 may employ one or more channel access methods, such as code divisionmultiple access (CDMA), time division multiple access (TDMA), frequencydivision multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrierFDMA (SC-FDMA), and the like.

As shown in FIG. 14A, the communications system 100 may include wirelesstransmit/receive units (WTRUs) 102 a. 102 b, 102 c, and/or 102 d (whichgenerally or collectively may be referred to as WTRU 102), a radioaccess network (RAN) 103/104/105, a core network 106/107/109, a publicswitched telephone network (PSTN) 108, the Internet 110, and othernetworks 112, though it will be appreciated that the disclosedembodiments contemplate any number of WTRUs, base stations, networks,and/or network elements. Each of the WTRUs 102 a, 102 b, 102 c, 102 dmay be any type of device configured to operate and/or communicate in awireless environment. By way of example, the WTRUs 102 a, 102 b, 102 c,102 d may be configured to transmit and/or receive wireless signals andmay include user equipment (UE), a mobile station, a fixed or mobilesubscriber unit, a pager, a cellular telephone, a personal digitalassistant (PDA), a smartphone, a laptop, a netbook, a personal computer,a wireless sensor, consumer electronics, and the like.

The communications systems 100 may also include a base station 114 a anda base station 114 b. Each of the base stations 114 a, 114 b may be anytype of device configured to wirelessly interface with at least one ofthe WTRUs 102 a, 102 b, 102 c, 102 d to facilitate access to one or morecommunication networks, such as the core network 106/107/109, theInternet 110, and/or the networks 112. By way of example, the basestations 114 a, 114 b may be a base transceiver station (BTS), a Node-B,an eNode B, a Home Node B, a Home eNode B, a site controller, an accesspoint (AP), a wireless router, and the like. While the base stations 114a, 114 b are each depicted as a single element, it will be appreciatedthat the base stations 114 a. 114 b may include any number ofinterconnected base stations and/or network elements.

The base station 114 a may be part of the RAN 103/104/105, which mayalso include other base stations and/or network elements (not shown),such as a base station controller (BSC), a radio network controller(RNC), relay nodes, etc. The base station 114 a and/or the base station114 b may be configured to transmit and/or receive wireless signalswithin a particular geographic region, which may be referred to as acell (not shown). The cell may further be divided into cell sectors. Forexample, the cell associated with the base station 114 a may be dividedinto three sectors. Thus, in one embodiment, the base station 114 a mayinclude three transceivers, i.e., one for each sector of the cell. Inanother embodiment, the base station 114 a may employ multiple-inputmultiple output (MIMO) technology and, therefore, may utilize multipletransceivers for each sector of the cell.

The base stations 114 a, 114 b may communicate with one or more of theWTRUs 102 a, 102 b, 102 c, 102 d over an air interface 115/116/117,which may be any suitable wireless communication link (e.g., radiofrequency (RF), microwave, infrared (IR), ultraviolet (UV), visiblelight, etc.). The air interface 115/116/117 may be established using anysuitable radio access technology (RAT).

More specifically, as noted above, the communications system 100 may bea multiple access system and may employ one or more channel accessschemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. Forexample, the base station 114 a in the RAN 103/104/105 and the WTRUs 102a, 102 b, 102 c may implement a radio technology such as UniversalMobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA),which may establish the air interface 115/116/117 using wideband CDMA(WCDMA). WCDMA may include communication protocols such as High-SpeedPacket Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may includeHigh-Speed Downlink Packet Access (HSDPA) and/or High-Speed UplinkPacket Access (HSUPA).

In another embodiment, the base station 114 a and the WTRUs 102 a, 102b, 102 c may implement a radio technology such as Evolved UMTSTerrestrial Radio Access (E-UTRA), which may establish the air interface115/116/117 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).

In other embodiments, the base station 114 a and the WTRUs 102 a. 102 b,102 c may implement radio technologies such as IEEE 802.16 (i.e.,Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000,CDMA2000 1×, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), InterimStandard 95 (IS-95), Interim Standard 856 (IS-856), Global System forMobile communications (GSM), Enhanced Data rates for GSM Evolution(EDGE), GSM EDGE (GERAN), and the like.

The base station 114 b in FIG. 14A may be a wireless router, Home NodeB, Home eNode B, or access point, for example, and may utilize anysuitable RAT for facilitating wireless connectivity in a localized area,such as a place of business, a home, a vehicle, a campus, and the like.In one embodiment, the base station 114 b and the WTRUs 102 c, 102 d mayimplement a radio technology such as IEEE 802.11 to establish a wirelesslocal area network (WLAN). In another embodiment, the base station 114 band the WTRUs 102 c, 102 d may implement a radio technology such as IEEE802.15 to establish a wireless personal area network (WPAN). In yetanother embodiment, the base station 114 b and the WTRUs 102 c, 102 dmay utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE,LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 14A,the base station 114 b may have a direct connection to the Internet 110.Thus, the base station 114 b may not be required to access the Internet110 via the core network 106/107/109.

The RAN 103/104/105 may be in communication with the core network106/107/109, which may be any type of network configured to providevoice, data, applications, and/or voice over internet protocol (VoIP)services to one or more of the WTRUs 102 a. 102 b, 102 c, 102 d. Forexample, the core network 106/107/109 may provide call control, billingservices, mobile location-based services, pre-paid calling, Internetconnectivity, video distribution, etc., and/or perform high-levelsecurity functions, such as user authentication. Although not shown inFIG. 14A, it will be appreciated that the RAN 103/104/105 and/or thecore network 106/107/109 may be in direct or indirect communication withother RANs that employ the same RAT as the RAN 103/104/105 or adifferent RAT. For example, in addition to being connected to the RAN103/104/105, which may be utilizing an E-UTRA radio technology, the corenetwork 106/107/109 may also be in communication with another RAN (notshown) employing a GSM radio technology.

The core network 106/107/109 may also serve as a gateway for the WTRUs102 a, 102 b, 102 c, 102 d to access the PSTN 108, the Internet 110,and/or other networks 112. The PSTN 108 may include circuit-switchedtelephone networks that provide plain old telephone service (POTS). TheInternet 110 may include a global system of interconnected computernetworks and devices that use common communication protocols, such asthe transmission control protocol (TCP), user datagram protocol (UDP)and the internet protocol (IP) in the TCP/IP internet protocol suite.The networks 112 may include wired or wireless communications networksowned and/or operated by other service providers. For example, thenetworks 112 may include another core network connected to one or moreRANs, which may employ the same RAT as the RAN 103/104/105 or adifferent RAT.

Some or all of the WTRUs 102 a, 102 b, 102 c, 102 d in thecommunications system 100 may include multi-mode capabilities, i.e., theWTRUs 102 a, 102 b, 102 c, 102 d may include multiple transceivers forcommunicating with different wireless networks over different wirelesslinks. For example, the WTRU 102 c shown in FIG. 14A may be configuredto communicate with the base station 114 a, which may employ acellular-based radio technology, and with the base station 114 b, whichmay employ an IEEE 802 radio technology.

FIG. 14B is a system diagram of an example WTRU 102. As shown in FIG.14B, the WTRU 102 may include a processor 118, a transceiver 120, atransmit/receive element 122, a speaker/microphone 124, a keypad 126, adisplay/touchpad 128, non-removable memory 130, removable memory 132, apower source 134, a global positioning system (GPS) chipset 136, andother peripherals 138. It will be appreciated that the WTRU 102 mayinclude any sub-combination of the foregoing elements while remainingconsistent with an embodiment. Also, embodiments contemplate that thebase stations 114 a and 114 b, and/or the nodes that base stations 114 aand 114 b may represent, such as but not limited to transceiver station(BTS), a Node-B, a site controller, an access point (AP), a home node-B,an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a homeevolved node-B gateway, and proxy nodes, among others, may include someor all of the elements depicted in FIG. 14B and described herein.

The processor 118 may be a general purpose processor, a special purposeprocessor, a conventional processor, a digital signal processor (DSP), aplurality of microprocessors, one or more microprocessors in associationwith a DSP core, a controller, a microcontroller, Application SpecificIntegrated Circuits (ASICs), Field Programmable Gate Array (FPGAs)circuits, any other type of integrated circuit (IC), a state machine,and the like. The processor 118 may perform signal coding, dataprocessing, power control, input/output processing, and/or any otherfunctionality that enables the WTRU 102 to operate in a wirelessenvironment. The processor 118 may be coupled to the transceiver 120,which may be coupled to the transmit/receive element 122. While FIG. 14Bdepicts the processor 118 and the transceiver 120 as separatecomponents, it will be appreciated that the processor 118 and thetransceiver 120 may be integrated together in an electronic package orchip.

The transmit/receive element 122 may be configured to transmit signalsto, or receive signals from, a base station (e.g., the base station 114a) over the air interface 115/116/117. For example, in one embodiment,the transmit/receive element 122 may be an antenna configured totransmit and/or receive RF signals. In another embodiment, thetransmit/receive element 122 may be an emitter/detector configured totransmit and/or receive IR, UV, or visible light signals, for example.In yet another embodiment, the transmit/receive element 122 may beconfigured to transmit and receive both RF and light signals. It will beappreciated that the transmit/receive element 122 may be configured totransmit and/or receive any combination of wireless signals.

In addition, although the transmit/receive element 122 is depicted inFIG. 14B as a single element, the WTRU 102 may include any number oftransmit/receive elements 122. More specifically, the WTRU 102 mayemploy MIMO technology. Thus, in one embodiment, the WTRU 102 mayinclude two or more transmit/receive elements 122 (e.g., multipleantennas) for transmitting and receiving wireless signals over the airinterface 115/116/117.

The transceiver 120 may be configured to modulate the signals that areto be transmitted by the transmit/receive element 122 and to demodulatethe signals that are received by the transmit/receive element 122. Asnoted above, the WTRU 102 may have multi-mode capabilities. Thus, thetransceiver 120 may include multiple transceivers for enabling the WTRU102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, forexample.

The processor 118 of the WTRU 102 may be coupled to, and may receiveuser input data from, the speaker/microphone 124, the keypad 126, and/orthe display/touchpad 128 (e.g., a liquid crystal display (LCD) displayunit or organic light-emitting diode (OLED) display unit). The processor118 may also output user data to the speaker/microphone 124, the keypad126, and/or the display/touchpad 128. In addition, the processor 118 mayaccess information from, and store data in, any type of suitable memory,such as the non-removable memory 130 and/or the removable memory 132.The non-removable memory 130 may include random-access memory (RAM),read-only memory (ROM), a hard disk, or any other type of memory storagedevice. The removable memory 132 may include a subscriber identitymodule (SIM) card, a memory stick, a secure digital (SD) memory card,and the like. In other embodiments, the processor 118 may accessinformation from, and store data in, memory that may not be physicallylocated on the WTRU 102, such as on a server or a home computer (notshown).

The processor 118 may receive power from the power source 134, and maybe configured to distribute and/or control the power to the othercomponents in the WTRU 102. The power source 134 may be any suitabledevice for powering the WTRU 102. For example, the power source 134 mayinclude one or more dry cell batteries (e.g., nickel-cadmium (NiCd),nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion),etc.), solar cells, fuel cells, and the like.

The processor 118 may also be coupled to the GPS chipset 136, which maybe configured to provide location information (e.g., longitude andlatitude) regarding the current location of the WTRU 102. In additionto, or in lieu of, the information from the GPS chipset 136, the WTRU102 may receive location information over the air interface 115/116/117from a base station (e.g., base stations 114 a, 114 b) and/or determineits location based on the timing of the signals being received from twoor more nearby base stations. It will be appreciated that the WTRU 102may acquire location information by way of any suitablelocation-determination method while remaining consistent with anembodiment.

The processor 118 may further be coupled to other peripherals 138, whichmay include one or more software and/or hardware modules that provideadditional features, functionality and/or wired or wirelessconnectivity. For example, the peripherals 138 may include anaccelerometer, an e-compass, a satellite transceiver, a digital camera(for photographs or video), a universal serial bus (USB) port, avibration device, a television transceiver, a hands free headset, aBluetooth® module, a frequency modulated (FM) radio unit, a digitalmusic player, a media player, a video game player module, an Internetbrowser, and the like.

FIG. 14C is a system diagram of the RAN 103 and the core network 106according to an embodiment. As noted above, the RAN 103 may employ aUTRA radio technology to communicate with the WTRUs 102 a, 102 b, 102 cover the air interface 115. The RAN 103 may also be in communicationwith the core network 106. As shown in FIG. 14C, the RAN 103 may includeNode-Bs 140 a, 140 b, 140 c, which may each include one or moretransceivers for communicating with the WTRUs 102 a, 102 b. 102 c overthe air interface 115. The Node-Bs 140 a. 140 b, 140 c may each beassociated with a particular cell (not shown) within the RAN 103. TheRAN 103 may also include RNCs 142 a, 142 b. It will be appreciated thatthe RAN 103 may include any number of Node-Bs and RNCs while remainingconsistent with an embodiment.

As shown in FIG. 14C, the Node-Bs 140 a, 140 b may be in communicationwith the RNC 142 a. Additionally, the Node-B 140 c may be incommunication with the RNC 142 b. The Node-Bs 140 a, 140 b, 140 c maycommunicate with the respective RNCs 142 a, 142 b via an Iub interface.The RNCs 142 a, 142 b may be in communication with one another via anIur interface. Each of the RNCs 142 a, 142 b may be configured tocontrol the respective Node-Bs 140 a, 140 b, 140 c to which it isconnected. In addition, each of the RNCs 142 a, 142 b may be configuredto carry out or support other functionality, such as outer loop powercontrol, load control, admission control, packet scheduling, handovercontrol, macrodiversity, security functions, data encryption, and thelike.

The core network 106 shown in FIG. 14C may include a media gateway (MGW)144, a mobile switching center (MSC) 146, a serving GPRS support node(SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each ofthe foregoing elements are depicted as part of the core network 106, itwill be appreciated that any one of these elements may be owned and/oroperated by an entity other than the core network operator.

The RNC 142 a in the RAN 103 may be connected to the MSC 146 in the corenetwork 106 via an IuCS interface. The MSC 146 may be connected to theMGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102 a, 102 b,102 c with access to circuit-switched networks, such as the PSTN 108, tofacilitate communications between the WTRUs 102 a. 102 b, 102 c andtraditional land-line communications devices.

The RNC 142 a in the RAN 103 may also be connected to the SGSN 148 inthe core network 106 via an IuPS interface. The SGSN 148 may beconnected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide theWTRUs 102 a, 102 b, 102 c with access to packet-switched networks, suchas the Internet 110, to facilitate communications between and the WTRUs102 a, 102 b. 102 c and IP-enabled devices.

As noted above, the core network 106 may also be connected to thenetworks 112, which may include other wired or wireless networks thatare owned and/or operated by other service providers.

FIG. 14D is a system diagram of the RAN 104 and the core network 107according to an embodiment. As noted above, the RAN 104 may employ anE-UTRA radio technology to communicate with the WTRUs 102 a. 102 b, 102c over the air interface 116. The RAN 104 may also be in communicationwith the core network 107.

The RAN 104 may include eNode-Bs 160 a, 160 b, 160 c, though it will beappreciated that the RAN 104 may include any number of eNode-Bs whileremaining consistent with an embodiment. The eNode-Bs 160 a. 160 b, 160c may each include one or more transceivers for communicating with theWTRUs 102 a, 102 b, 102 c over the air interface 116. In one embodiment,the eNode-Bs 160 a, 160 b, 160 c may implement MIMO technology. Thus,the eNode-B 160 a, for example, may use multiple antennas to transmitwireless signals to, and receive wireless signals from, the WTRU 102 a.

Each of the eNode-Bs 160 a, 160 b, 160 c may be associated with aparticular cell (not shown) and may be configured to handle radioresource management decisions, handover decisions, scheduling of usersin the uplink and/or downlink, and the like. As shown in FIG. 14D, theeNode-Bs 160 a. 160 b, 160 c may communicate with one another over an X2interface.

The core network 107 shown in FIG. 14D may include a mobility managementgateway (MME) 162, a serving gateway 164, and a packet data network(PDN) gateway 166. While each of the foregoing elements are depicted aspart of the core network 107, it will be appreciated that any one ofthese elements may be owned and/or operated by an entity other than thecore network operator.

The MME 162 may be connected to each of the eNode-Bs 160 a, 160 b, 160 cin the RAN 104 via an SI interface and may serve as a control node. Forexample, the MME 162 may be responsible for authenticating users of theWTRUs 102 a, 102 b, 102 c, bearer activation/deactivation, selecting aparticular serving gateway during an initial attach of the WTRUs 102 a,102 b, 102 c, and the like. The MME 162 may also provide a control planefunction for switching between the RAN 104 and other RANs (not shown)that employ other radio technologies, such as GSM or WCDMA.

The serving gateway 164 may be connected to each of the eNode-Bs 160 a.160 b, 160 c in the RAN 104 via the SI interface. The serving gateway164 may generally route and forward user data packets to/from the WTRUs102 a, 102 b, 102 c. The serving gateway 164 may also perform otherfunctions, such as anchoring user planes during inter-eNode B handovers,triggering paging when downlink data is available for the WTRUs 102 a.102 b, 102 c, managing and storing contexts of the WTRUs 102 a, 102 b,102 c, and the like.

The serving gateway 164 may also be connected to the PDN gateway 166,which may provide the WTRUs 102 a, 102 b, 102 c with access topacket-switched networks, such as the Internet 110, to facilitatecommunications between the WTRUs 102 a. 102 b, 102 c and IP-enableddevices.

The core network 107 may facilitate communications with other networks.For example, the core network 107 may provide the WTRUs 102 a, 102 b,102 c with access to circuit-switched networks, such as the PSTN 108, tofacilitate communications between the WTRUs 102 a. 102 b, 102 c andtraditional land-line communications devices. For example, the corenetwork 107 may include, or may communicate with, an IP gateway (e.g.,an IP multimedia subsystem (IMS) server) that serves as an interfacebetween the core network 107 and the PSTN 108. In addition, the corenetwork 107 may provide the WTRUs 102 a, 102 b, 102 c with access to thenetworks 112, which may include other wired or wireless networks thatare owned and/or operated by other service providers.

FIG. 14E is a system diagram of the RAN 105 and the core network 109according to an embodiment. The RAN 105 may be an access service network(ASN) that employs IEEE 802.16 radio technology to communicate with theWTRUs 102 a, 102 b, 102 c over the air interface 117. As will be furtherdiscussed below, the communication links between the differentfunctional entities of the WTRUs 102 a, 102 b, 102 c, the RAN 105, andthe core network 109 may be defined as reference points.

As shown in FIG. 14E, the RAN 105 may include base stations 180 a, 180b, 180 c, and an ASN gateway 182, though it will be appreciated that theRAN 105 may include any number of base stations and ASN gateways whileremaining consistent with an embodiment. The base stations 180 a, 180 b,180 c may each be associated with a particular cell (not shown) in theRAN 105 and may each include one or more transceivers for communicatingwith the WTRUs 102 a, 102 b, 102 c over the air interface 117. In oneembodiment, the base stations 180 a, 180 b, 180 c may implement MIMOtechnology. Thus, the base station 180 a, for example, may use multipleantennas to transmit wireless signals to, and receive wireless signalsfrom, the WTRU 102 a. The base stations 180 a, 180 b, 180 c may alsoprovide mobility management functions, such as handoff triggering,tunnel establishment, radio resource management, traffic classification,quality of service (QoS) policy enforcement, and the like. The ASNgateway 182 may serve as a traffic aggregation point and may beresponsible for paging, caching of subscriber profiles, routing to thecore network 109, and the like.

The air interface 117 between the WTRUs 102 a, 102 b, 102 c and the RAN105 may be defined as an R1 reference point that implements the IEEE802.16 specification. In addition, each of the WTRUs 102 a, 102 b, 102 cmay establish a logical interface (not shown) with the core network 109.The logical interface between the WTRUs 102 a, 102 b, 102 c and the corenetwork 109 may be defined as an R2 reference point, which may be usedfor authentication, authorization, IP host configuration management,and/or mobility management.

The communication link between each of the base stations 180 a, 180 b,180 c may be defined as an R8 reference point that includes protocolsfor facilitating WTRU handovers and the transfer of data between basestations. The communication link between the base stations 180 a, 180 b,180 c and the ASN gateway 182 may be defined as an R6 reference point.The R6 reference point may include protocols for facilitating mobilitymanagement based on mobility events associated with each of the WTRUs102 a. 102 b, 102 c.

As shown in FIG. 14E, the RAN 105 may be connected to the core network109. The communication link between the RAN 105 and the core network 109may defined as an R3 reference point that includes protocols forfacilitating data transfer and mobility management capabilities, forexample. The core network 109 may include a mobile IP home agent(MIP-HA) 184, an authentication, authorization, accounting (AAA) server186, and a gateway 188. While each of the foregoing elements aredepicted as part of the core network 109, it will be appreciated thatany one of these elements may be owned and/or operated by an entityother than the core network operator.

The MIP-HA may be responsible for IP address management, and may enablethe WTRUs 102 a, 102 b, 102 c to roam between different ASNs and/ordifferent core networks. The MIP-HA 184 may provide the WTRUs 102 a, 102b, 102 c with access to packet-switched networks, such as the Internet110, to facilitate communications between the WTRUs 102 a, 102 b, 102 cand IP-enabled devices. The AAA server 186 may be responsible for userauthentication and for supporting user services. The gateway 188 mayfacilitate interworking with other networks. For example, the gateway188 may provide the WTRUs 102 a, 102 b, 102 c with access tocircuit-switched networks, such as the PSTN 108, to facilitatecommunications between the WTRUs 102 a, 102 b, 102 c and traditionalland-line communications devices. In addition, the gateway 188 mayprovide the WTRUs 102 a, 102 b, 102 c with access to the networks 112,which may include other wired or wireless networks that are owned and/oroperated by other service providers.

Although not shown in FIG. 14E, it will be appreciated that the RAN 105may be connected to other ASNs and the core network 109 may be connectedto other core networks. The communication link between the RAN 105 theother ASNs may be defined as an R4 reference point, which may includeprotocols for coordinating the mobility of the WTRUs 102 a, 102 b. 102 cbetween the RAN 105 and the other ASNs. The communication link betweenthe core network 109 and the other core networks may be defined as an R5reference, which may include protocols for facilitating interworkingbetween home core networks and visited core networks.

The processes and instrumentalities described herein may apply in anycombination, may apply to other wireless technology, and for otherservices.

A WTRU may refer to an identity of the physical device, or to the user'sidentity such as subscription related identities, e.g., MSISDN, SIP URI,etc. WTRU may refer to application-based identities, e.g., user namesthat may be used per application.

Although features and elements are described above in particularcombinations, one of ordinary skill in the art will appreciate that afeature or element may be used alone or in any combination with theother features and elements. In addition, the methods described hereinmay be implemented in a computer program, software, or firmwareincorporated in a computer-readable medium for execution by a computeror processor. Examples of computer-readable media include electronicsignals (transmitted over wired or wireless connections) andcomputer-readable storage media. Examples of computer-readable storagemedia include, but are not limited to, a read only memory (ROM), arandom access memory (RAM), a register, cache memory, semiconductormemory devices, magnetic media such as internal hard disks and removabledisks, magneto-optical media, and optical media such as CD-ROM disks,and digital versatile disks (DVDs). A processor in association withsoftware may be used to implement a radio frequency transceiver for usein a WTRU, UE, terminal, base station, RNC, or any host computer.

1.-35. (canceled)
 36. A wireless transmit/receive unit (WTRU), the WTRUcomprising: a memory; and a processor configured to: receive a mediapresentation description (MPD) file identifying a plurality ofrepresentations for multimedia content; receive at least one metadatafile indicating complexity information for the plurality ofrepresentations, the at least one metadata file being a different filethan the MPD file; determine a first representation for downloading afirst video segment based on the complexity information for theplurality of representations in the at least one metadata file; requestthe first video segment of the first representation; receive the firstvideo segment of the first representation; and decode the first videosegment.
 37. The WTRU of claim 36, wherein the processor is configuredto receive a plurality of metadata files, the plurality of metadatafiles indicating the complexity information for the plurality ofrepresentations.
 38. The WTRU of claim 36, wherein the determination ofthe first representation is based on a first complexity information ofthe first representation, and the processor is configured to: determinea second complexity information for selecting a second representation ofa second video segment based on the first complexity information of thefirst representation and a power consumption of the firstrepresentation; determine the second representation for requesting thesecond video segment based on the second complexity information; requestthe second video segment of the second representation; receive thesecond video segment of the second representation; and decode the secondvideo segment.
 39. The WTRU of claim 38, wherein the processor isconfigured to determine the power consumption of the firstrepresentation based on a power dissipated during a duration whiledecoding the first video segment of the first representation.
 40. TheWTRU of claim 38, wherein the processor is configured to reduceoperations based on the determination of the second complexityinformation.
 41. The WTRU of claim 38, wherein the at least one metadatafile carries the complexity information for the plurality ofrepresentations, and the MPD comprises information indicatingavailability of the complexity information for the plurality ofrepresentations.
 42. The WTRU of claim 38, wherein the processor isfurther configured to: determine a length of the multimedia content;determine a power needed to play the video based on the first complexityinformation and the length of the multimedia content; and determine thesecond complexity information based on the power needed to play themultimedia content.
 43. The WTRU of claim 38, wherein the processor isfurther configured to: determine that the first complexity informationindicates that a power used to play the multimedia content will exceed aremaining battery capacity; and determine the second complexityinformation such that the multimedia content can be played within theremaining battery capacity.
 44. The WTRU of claim 36, wherein themetadata file is a metadata file defined by moving picture experts group(MPEG) Green.
 45. The WTRU of claim 36, wherein the at least onemetadata file indicates a relative complexity metric for each of theplurality of representations.
 46. A method comprising: receiving a mediapresentation description (MPD) file identifying a plurality ofrepresentations for multimedia content; receiving at least one metadatafile indicating complexity information for the plurality ofrepresentations, the at least one metadata file being a different filethan the MPD file; determining a first representation for downloading afirst video segment based on the complexity information for theplurality of representations in the at least one metadata file;requesting the first video segment of the first representation;receiving the first video segment of the first representation; anddecoding the first video segment.
 47. The method of claim 46, furthercomprising receiving a plurality of metadata files, the plurality ofmetadata files indicating the complexity information for the pluralityof representations.
 48. The method of claim 46, wherein determining thefirst representation is based on a first complexity information of thefirst representation, and the method further comprises: determining asecond complexity information for selecting a second representation of asecond video segment based on the first complexity information of thefirst representation and a power consumption of the firstrepresentation; determining the second representation for requesting thesecond video segment based on the second complexity information;requesting the second video segment of the second representation;receiving the second video segment of the second representation; anddecoding the second video segment.
 49. The method of claim 48, furthercomprising determining the power consumption of the first representationbased on a power dissipated during a duration while decoding the firstvideo segment of the first representation.
 50. The method of claim 48,further comprising reducing operations based on the determination of thesecond complexity information.
 51. The method of claim 48, wherein theat least one metadata file carries the complexity information for theplurality of representations, and the MPD comprises informationindicating availability of the complexity information for the pluralityof representations.
 52. The method of claim 48, further comprising:determining a length of the multimedia content; determining a powerneeded to play the video based on the first complexity information andthe length of the multimedia content; and determining the secondcomplexity information based on the power needed to play the multimediacontent.
 53. The method of claim 48, further comprising: determiningthat the first complexity information indicates that a power used toplay the multimedia content will exceed a remaining battery capacity;and determining the second complexity information such that themultimedia content can be played within the remaining battery capacity.54. The method of claim 46, wherein the metadata file is a metadata filedefined by moving picture experts group (MPEG) Green.
 55. The method ofclaim 46, wherein the at least one metadata file indicates a relativecomplexity metric for each of the plurality of representations.